System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles

ABSTRACT

A system and method for mitigating or avoiding risks due to hazards encountered by platooning vehicles. The system and method involve interrogating, with one or more sensors, a space radially extending from a lead vehicle as the lead vehicle travels over the road surface, perceiving the environment within the space, ascertaining a hazard caused by an object in the space, and causing a following vehicle, operating in a platoon with the lead vehicle, to take a preemptive braking action to avoid or mitigate risks resulting from the hazard caused by the object in the space.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority of U.S. Provisional Application No.62/638,794, filed on Mar. 5, 2018. This Application is also aContinuation-in-Part of U.S. application Ser. No. 15/589,124, filed onMay 8, 2017, which is a Continuation of U.S. application Ser. No.14/855,044, filed Sep. 15, 2015 (now U.S. Pat. No. 9,645,579, issued May9, 2017), which is a 371 of International Application No.PCT/US2014/030770, filed on Mar. 17, 2014, which claims priority of U.S.Provisional Application No. 61/792,304, filed Mar. 15, 2013. Thisapplication is also a Continuation-in-Part of U.S. application Ser. No.15/607,902, filed on May 30, 2017 which claims priority of U.S.Provisional Application Nos.: 62/343,819, filed May 31, 2016;62/363,192, filed Jul. 15, 2016; and 62/377,970, filed on Aug. 22, 2016.This application is also a Continuation-in-Part of U.S. application Ser.No. 15/607,316, filed May 26, 2017, which is a Continuation of U.S.application Ser. No. 14/292,583, filed May 30, 2014 (now U.S. Pat. No.9,665,102, issued May 30, 2017), which is a Division of U.S. applicationSer. No. 13/542,622, filed Jul. 5, 2012 (now U.S. Pat. No. 8,744,666,issued Jun. 3, 2014) and U.S. application Ser. No. 13/542,627, filed onJul. 5, 2012 (now U.S. Pat. No. 9,582,006, issued Feb. 28, 2017) whichclaims priority of U.S. Provisional Application No. 61/505,076, filed onJul. 6, 2011. All of the aforementioned priority applications areincorporated herein by reference in their entirety for all purposes.

BACKGROUND

The present application relates generally to controllers, architectures,methods and systems for enabling vehicles to closely follow one anothersafely using automatic or partially automatic control, and moreparticularly, to a system and method for mitigating or avoiding risksdue to hazards encountered by connected vehicles operating in a platoon.

In recent years significant strides have been made in the field ofautomated vehicle control. One segment of vehicle automation relates tovehicular convoying systems that enable vehicles to follow closelytogether in a safe, efficient and convenient manner Following closelybehind another vehicle has the potential for significant fuel savingsbenefits, but is generally unsafe when done manually by the driver.Known vehicle convoying systems, often interchangeable referred to as“platooning” or “connected vehicles”, calls for one or more followingvehicle(s) closely following a lead vehicle in an automatic orsemi-automatically controlled manner.

The fuel efficiency advantages of platooning connected vehicles isparticularly noticeable in fields such as the trucking industry in whichlong distances tend to be traveled at highway speeds. One of theon-going challenges of vehicle platooning and convoying systems iscreating controller systems architectures that effectively maintain agap between vehicles while meeting stringent safety standards asrequired for integration of connected vehicles into mainstream roadvehicles.

Maintaining road safety and avoiding collisions due to hazardsencountered on the road is also very important with platooning. Althoughthe platooning of connected vehicles has a very good safety record,there is always a need for improvement.

A system and method for mitigating or avoiding risks due to hazardsencountered by platooning vehicles is therefore needed.

SUMMARY

A system and method for mitigating or avoiding risks due to hazardsencountered by connected vehicles operating in a platoon is described.The system and method involve operating a following vehicle in a platoonbehind a lead vehicle, receiving data generated by one or more sensorsarranged to interrogate a space radially extending from the lead vehicleas the lead vehicle travels over the road surface, ascertaining a hazardcaused by an object in the space, and causing the following vehicle totake a preemptive action to avoid or mitigate the hazard caused by theobject in the space, the preemptive action taken by the followingvehicle prior to the lead vehicle taking any action in response to thehazard caused by the object.

In one non-exclusive embodiment, a plurality of tiered severity threatlevels is defined, each level having one or more correspondingpreemptive action(s) respectively. When a threat is perceived, one ofthe tiered severity threat levels commensurate with the threat isselected. The corresponding one or more preemptive action(s) is/are thenimplemented by the following vehicle to mitigate or avoid the risksassociated with the object. In one particular non-exclusive embodiment,the tiered threat levels include low, moderate, high and emergency.

In yet another non-exclusive embodiment, one of the preemptive actionsmay involve increasing the gap between the two vehicles by decreasingthe relative velocity of the following vehicle(s) prior to taking anypreemptive action by the lead vehicle. By reducing the relative velocityof the following vehicle first, the gap between the vehicles will grow.

In yet other alternative embodiments, the gap can be increase whileeither maintaining or dissolving the platoon. In either case, a normaloperating gap may be reestablished once the perceived threat has passed.

In yet another embodiment, raw data collected by the one or moresensors, on the lead vehicle, is transmitted by the lead vehicle to thefollowing vehicle. In response, the following vehicle is responsible forperceiving the environment within the space radially extending from thelead vehicle, ascertaining the hazard caused by the object in the space,and taking a preemptive action prior to and/or without waiting for thelead vehicle taking any preemptive action.

In an alternative to the above embodiment, the lead vehicle isresponsible for perceiving the environment in the space, ascertainingthe hazard level, and then transmitting one or more coded commands, eachindicative or a preemptive action, to the following vehicle. Inresponse, the following vehicle interprets the commands and implementsthe preemptive action(s) prior to the lead vehicle taking any preemptiveaction.

In yet other embodiments, pre-cognitive braking is implemented withplatooning vehicles. A notice is sent to the following vehicle by thelead vehicle in response to a braking event by the lead vehicle. Inresponse to the notice, the following vehicle initiates a braking beforethe lead vehicle, resulting in an increase of a gap maintained betweenthe two vehicles.

In yet other embodiments, a system operating onboard a vehicle isconfigured to receive data from one or more sensors external to thevehicle that are arranged to sense a driving condition in the vicinityof the vehicle. In response, the system is arranged to make a decisionor take an action at least in part based on the received data.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention and the advantages thereof, may best be understood byreference to the following description taken in conjunction with theaccompanying drawings in which:

FIG. 1 is a block diagram of a controller architecture suitable for usein an automated or partially automated vehicle control system thatsupports platooning.

FIG. 2 is a block diagram of a representative platoon controllerarchitecture suitable for use in the automated or partially automatedvehicle control system of FIG. 1.

FIG. 3 is a block diagram of a gap controller in accordance with oneembodiment.

FIGS. 4A-4C are a series of diagrams illustrating different controlstates used by a gap regulator in accordance with one embodiment duringdifferent operational states.

FIG. 5 is a state space diagram illustrating a sliding mode controlscheme.

FIG. 6 is a specific ASIL compliant controller hardware architecturesuitable for use in an automated or partially automated vehicle controlsystem that supports platooning.

FIG. 7 illustrates components of a gateway in accordance with oneembodiment.

FIG. 8 is a diagram showing a lead vehicle and several followingvehicle(s) encountering a hazard represented by an object whiletraveling across a road surface.

FIGS. 9A-9C are a set of block diagrams illustrating a non-exclusiveembodiment of a system for mitigating or avoiding risks due to hazardsencountered by connected vehicles in accordance with the presentinvention.

FIGS. 10A-10C are another set of block diagrams illustrating anothernon-exclusive embodiment of a system for mitigating or avoiding risksdue to hazards encountered by connected vehicles in accordance with thepresent invention.

FIG. 11 illustrates an illustrative plurality of tiered severity threatlevels each having one or more corresponding preemptive action(s) inaccordance with a non-exclusive embodiment of the present invention.

FIG. 12 illustrates several categories of preemptive actions inaccordance with a non-exclusive embodiment of the present invention.

FIG. 13 illustrates a flow chart illustrating operational steps inaccordance with a non-exclusive embodiment of the present invention.

FIG. 14 illustrates two vehicles operating in a platoon in accordancewith the present invention.

FIG. 15 illustrates a plot showing a gap between two platooning vehiclesduring pre-cognitive braking in accordance with a non-exclusiveembodiment of the invention.

FIG. 16 illustrates a flow chart detailing steps for implementingpre-cognitive braking in accordance with the a non-exclusive embodimentof the invention.

DETAILED DESCRIPTION

The present invention will now be described in detail with reference toseveral embodiments thereof as illustrated in the accompanying drawings.In the following description, numerous specific details are set forth inorder to provide a thorough understanding of embodiments of the presentinvention, including the description of a plurality of different aspectsof the invention, including, in some case, one or more alternatives. Itwill be apparent to those skilled in the art that the invention can bepractice without implementing all of the features disclosed herein.

Platooning

The Applicant has proposed various vehicle platooning systems in which asecond, and potentially additional, vehicle(s) is/are automatically, orsemi-automatically controlled to closely follow a lead vehicle in a safemanner By way of example, U.S. application Ser. Nos. 15/605,456,15/607,902; 13/542,622 and 13/542,627; U.S. Provisional Application Nos.62/377,970 and 62/343,819; and PCT Application Nos. PCT/US2014/030770,PCT/US2016/049143 and PCT/US2016/060167 describe various vehicleplatooning systems in which a trailing vehicle is at least partiallyautomatically controlled to closely follow a designated lead vehicle.Each of these earlier applications is incorporated herein by reference.

One of the goals of platooning is typically to maintain a desiredlongitudinal distance between the platooning vehicles, which isfrequently referred to herein as the “desired gap”. That is, it isdesirable for the trailing vehicle (e.g., a trailing truck) to maintaina designated gap relative to a specific vehicle (e.g., a lead truck).The vehicles involved in a platoon will typically have sophisticatedcontrol systems suitable for initiating a platoon, maintaining the gapunder a wide variety of different driving conditions, and gracefullydissolving the platoon as appropriate.

The architecture and design of control systems suitable for implementingvehicle platooning may vary widely. The specific controller design canvary based on the level of automation contemplated for the controller,as well as the nature of and equipment available on the host vehiclesparticipating in the platoon. By way of example, FIG. 1 diagrammaticallyillustrates a vehicle control architecture that is suitable for use withplatooning tractor-trailer trucks. The specific controller illustratedis primarily designed for use in conjunction with a platooning system inwhich both vehicles include an active driver. The driver of the leadvehicle being fully responsible for control of the front vehicle. The adriver of the trailing vehicle is responsible for steering the trailingvehicle, but the platoon controller 110 is primarily responsible forcontrolling the engine torque and braking requests of the followingvehicle during active platooning. However, it should be appreciated thatgenerally similar control schemes can be used in systems whichcontemplate more automated control of one or both of the platoonpartners.

In the illustrated embodiment illustrated in FIG. 1, a platooncontroller 110, receives inputs from a number of sensors 130 on thetractor and/or one or more trailers or other connected units, and anumber of actuators and actuator controllers 150 arranged to controloperation of the tractor's powertrain and other vehicle systems. Anactuator interface 160 may be provided to facilitate communicationsbetween the platoon controller 110 and the actuator controllers 150.

The platoon controller 110 also interacts with an inter-vehiclecommunications controller 170 which orchestrates communications with theplatoon partner and a Network Operations Center (NOC) communicationscontroller 180 that orchestrates communications with a NOC. The vehiclealso preferably has selected configuration files 190 that include knowninformation about the vehicle.

Some of the functional components of the platoon controller 110 includegap controller 112, a variety of estimators 114, one or more partnervehicle trackers 116 and various monitors 118. In many applications, theplatoon controller 110 will include a variety of other components 119 aswell. Exemplary embodiments of the platoon controller 110 and gapcontroller 112 are described in more detail below with reference toFIGS. 2 and 3.

Some of the sensors utilized by the platoon controller 110 may includeGNSS (GPS) unit 131, wheel speed sensors 132, inertial measurementdevices 134, radar unit 137, LIDAR unit 138, cameras 139, acceleratorpedal position sensor 141, steering wheel position sensor 142, brakepedal position sensor 143, and various accelerometers 144. Of course,not all of these sensors will be available on all vehicles involved in aplatoon and not all of these sensors are required in any particularembodiment. A variety of other sensor 149 (now existing or laterdeveloped or commercially deployed) may be additionally or alternativelybe utilized by the platoon controller in other embodiments. In theprimary embodiments described herein, GPS position data is used.However, GPS is just one of the currently available global navigationsatellite systems (GNSS). Therefore, it should be appreciated that datafrom any other GNSS system or from other suitable position sensingsystems may be used in place of, or in addition to, the GPS system.

Many (but not all) of the described sensors, including wheel speedsensors, 132, radar unit 137, accelerator pedal position sensor 141,steering wheel position sensor 142, brake pedal position sensor 143, andaccelerometer 144 are relatively standard equipment on newer trucks(tractors) used to pull semi-trailers. However, others, such as the GNSSunit 131 and LIDAR unit 138 (if used) are not currently standardequipment on such tractors or may not be present on a particular vehicleand may be installed as needed or desired to help support platooning.

Some of the vehicle actuators controllers 150 that the platooncontroller may direct at least in part include engine torque controller152 (which is often part of the integrated functionality of an enginecontrol unit (ECU) or powertrain control module (PCM)), transmissioncontroller 154, brake controller 156, steering controller 157 (whenautomated steering is provided); and clutch controller 158. Of course,not all of these actuator controllers will be available or are requiredin any particular embodiment and it may be desirable to interface with avariety of other vehicle actuator controllers 159 that may be availableon the controlled vehicle as well. Therefore, it should be appreciatedthat the specific actuator controllers 150 directed or otherwiseutilized by the platoon controller on any particular controlled vehiclemay vary widely. Further, the capabilities of any particular actuatorcontroller (e.g. engine torque controller 152), as well as its interface(e.g., the nature and format of the commands, instructions, requests andmessages it can handle or generate) will often vary with the make andmodel of that particular actuator controller. Therefore, an actuatorinterface 160 is preferably provided to translate requests, commands,messages and instructions from the platoon controller 110 into formatsthat are appropriate for the specific actuator controller hardware andsoftware utilized on the controlled vehicle. The actuator interface 160also provides a mechanism for communicating/translating messages,commands, instructions and requests received from the various actuatorcontrollers back to the platoon controller 110. Typically an appropriateactuator interface would be provided to interact with each of thespecific vehicle controllers utilized. In various embodiments, this mayinclude one or more of an engine torque interface 161, a brake interface162, a transmission interface 164, a retarder interface 165 (if aseparate retarder controller is used), a steering interface 167, and/orany other appropriate controller interface 169.

Large trucks and other heavy vehicles frequently have multiple systemsfor “braking” the truck. These include the traditional brake systemassemblies mounted in the wheels of the vehicle—which are often referredto in the industry as the “foundation brakes.” Most large trucks/heavyvehicles also have a mechanism referred to as a “retarder” that is usedto augment the foundation brakes and serve as an alternative mechanismfor slowing the vehicle or to help prevent the vehicle from acceleratingdown a hill. Often, the retarder will be controlled by the engine torquecontroller 152 and in such embodiments, the retarder can be controlledby sending appropriate torque commands (which may be negative) to theengine torque controller 152. In other embodiments a separate retardercontroller (not shown) may be accessible to, and therefore directed by,platoon controller 110 through an appropriate retarder interface 165. Instill other embodiments, the platoon controller 110 may separatelydetermine a retard command that it sends to the actuator interface 160.In such embodiments the actuator interface will interpret the retardcommand and pass on appropriate retardation control commands to the ECUor other appropriate vehicle controller.

The communications between vehicles may be directed over any suitablechannel and may be coordinated by inter-vehicle communicationscontroller 170. By way of example, the Dedicated Short RangeCommunications (DSRC) protocol (e.g. the IEEE 802.11p protocol), whichis a two-way short to medium range wireless communications technologythat has been developed for vehicle to vehicle communications, workswell. Of course other communications protocols and channels may be usedin addition to or in place of a DSRC link. For example, the intervehicle communications may additionally or alternatively be transmittedover a cellular communications channel such as 4G LTE Direct, 5G, aCitizen's Band (CB) Radio channel, one or more General Mobile RadioService (GMRS) bands, and one or more Family Radio Service (FRS) bandsor any other now existing or later developed communications channelsusing any suitable communication protocol.

In various embodiments, the transmitted information may include thecurrent commands generated by the platoon controller 110 such asrequested/commanded engine torque 280, requested/commanded brakingdeceleration 282. They may also include steering commands, gearcommands, etc. when those aspects are controlled by platoon controller110. Corresponding information is received from the partner vehicle,regardless of whether those commands are generated by a platooncontroller or other suitable controller on the partner vehicle (e.g., anadaptive cruise control system (ACC) or a collision mitigation system(CMS)), or through other or more traditional mechanisms—as for example,in response to driver inputs (e.g., accelerator pedal position, brakeposition, steering wheel position, etc.).

In many embodiments, much or all of the tractor sensor informationprovided to platoon controller 110 is also transmitted to the platoonpartner and corresponding information is received from the platoonpartner so that the platoon controllers 110 on each vehicle can developan accurate model of what the partner vehicle is doing. The same is truefor any other relevant information that is provided to the platooncontroller, including any vehicle configuration information 190 that isrelevant to the platoon controller. It should be appreciated that thespecific information transmitted may vary widely based on therequirements of the platoon controllers 110, the sensors and actuatorsavailable on the respective vehicles, and the specific knowledge thateach vehicle may have about itself.

The information transmitted between vehicles may also includeinformation about intended future actions. For example, if the leadvehicle knows it approaching a hill, it may expect to increase itstorque request (or decrease its torque request in the context of adownhill) in the near future and that information can be conveyed to atrailing vehicle for use as appropriate by the platoon controller 110.Of course, there is a wide variety of other information that can be usedto foresee future torque or braking requests and that information can beconveyed in a variety of different forms. In some embodiments, thenature of the expected events themselves can be indicated (e.g., a hill,or curve or exit is approaching) together with the expected timing ofsuch events. In other embodiments, the intended future actions can bereported in the context of expected control commands such as theexpected torques and/or other control parameters and the timing at whichsuch changes are expected. Of course, there are a wide variety ofdifferent types of expected events that may be relevant to the platooncontrol.

The communications between the vehicles and the NOC may be transmittedover a variety of different networks, such as the cellular network,various Wi-Fi networks, satellite communications networks and/or any ofa variety of other networks as appropriate. The communications with theNOC may be coordinated by NOC communications controller 180. Theinformation transmitted to and/or received from the NOC may vary widelybased on the overall system design. In some circumstances, the NOC mayprovide specific control parameters such as a target gap tolerance.These control parameters or constraints may be based on factors known atthe NOC such as speed limits, the nature of the road/terrain (e.g.,hilly vs. flat, winding vs. straight, etc.) weather conditions, trafficor road conditions, etc. In other circumstances the NOC may provideinformation such information to the platoon controller. The NOC may alsoprovide information about the partner vehicle including itsconfiguration information and any known relevant information about itscurrent operational state such as weight, trailer length, etc.

The configuration file 190 may include a wide variety of informationabout the host vehicle that may be considered relevant to thecontroller. By way of example, some of the information might include thevehicle's specification including such things as engine performancecharacteristics, available sensors, the nature of its braking system,the location of its GNSS antenna relative to the front of the cab, gearratios, differential ratios etc.

FIG. 2 illustrates a particular embodiment of a platoon controller 110.In the illustrated embodiment, the platoon controller 110 includes a gapcontroller 112, a plurality of estimators 114, one or more trackers 116,any desired monitors 118 and potentially any of a variety of othercomponents 119.

In the illustrated embodiment, the gap controller 112 includes a targetand state setter 200, a gap regulator 210 and a gap estimator 240. Ingeneral, the target and state setter 200 is arranged to determine theintended operational mode (state) of the gap regulator 210 and thevalues of any variable control parameters that are appropriate for usein that operational mode.

The gap regulator 210 is arranged to control the trailing platoonpartner in the manner designated by the target and state setter 200. Inthe gap control operational mode, the gap regulator 210 controls thevehicle in a manner that seeks to attain and maintain the desired gap inaccordance with any designated control parameters specified by the statesetter 200. In other modes, the gap regulator 210 controls the vehiclein a manner that seeks to attain the appropriate response for theselected operational mode.

The gap estimator 240 is arranged to estimate/determine the current gapbased on actual measurements and/or other information that is availableto the platoon controller 110. It should be apparent that an accurateunderstanding of the current gap is important to successful operation ofthe gap regulator. At the same time, it should be appreciated that anymeasurement system has inherent tolerances and can be subject toreporting errors and/or may become unavailable in some circumstances.Thus, the gap estimator 240 is configured to receive information frommultiple position or relative position related sensors and to fuse suchdata into a reliable estimate of the current gap.

The torque and braking requests generated by GAP regulator 210 are sentto the appropriate actuator interface (e.g., engine torque interface 161and brake interface 162 respectively). The engine torque interface 161then forwards an appropriate torque command to engine torque controller152 which directs the delivery of the requested torque by directingvarious engine operating parameters such as fuel charge, valve timing,retarder state, etc. appropriately. The brake interface 162 generates anappropriate brake request that is sent to the brake controller 156.

A particular embodiment of gap controller 112 is described in moredetail below with reference to FIG. 3.

Returning to FIG. 2, there are a variety of estimators 114 that areuseful for the gap controller 112. In various embodiments these mayinclude one or more of a mass estimator 271, a drag estimator 273, aground speed estimator 275, a gyro bias estimator 277 and/or otherestimators 279.

The mass estimator 271 is arranged to estimate the respective masses ofthe platoon partners. These mass estimations may be used by the gapcontroller 112 to help scale its torque and brake requests appropriatelybased on the respective weights (masses) of the platoon partners.

The drag estimator 273 is arranged to estimate the respective dragresistances of the platoon partners. These drag resistance estimates mayalso be used by the gap controller to help adjust its torque and brakerequests appropriately. In general, the drag resistance of anyparticular truck or other vehicle can vary based on a variety of factorsincluding: (a) its drag profile (which in the context of a truck maychange based on the trailer being pulled—if any, or othercharacteristics of the load); (b) the vehicle's current speed, (c) windspeed and direction, (d) rolling resistance, (e) platoon state (e.g.,whether a platoon is active, the position of the vehicle within theplatoon, the gap), (f) bearing wear, etc.

The ground speed estimator 275 is arranged to estimate the actual groundspeed of the respective platoon partners. Many trucks and other vehicleshave wheel speed sensors that can quite accurately measure therotational speed of the associated wheels. The actual ground speed atwhich the vehicles are traveling will vary based on the respectivediameters of the wheels and slip conditions of the tires. The precisediameter of the wheels can vary based on the tires used. Furthermore,the diameter of the wheels will vary over time with tire wear, changesin ambient temperature and other factors. The wheel diameter will evenchange over the course of a particular trip as the tires heat up (orotherwise change in temperature) during use. In practice, all of thesevariations in wheel diameter are potentially significant enough toimpact the gap estimation and gap control. Therefore, the ground speedestimator 275 is arranged to estimate the actual ground speed based onmeasured wheel speed and other available information such as GNSSinformation. The ground speed estimates are particularly useful in timeswhen tracker based gap measurements (e.g., radar, cameras, LIDAR, etc.)aren't available—which may occur, for example, when the platoon partnersare laterally offset due to a lane change, etc.

Several of the measurements utilized by the gap controller 112 areinertial measurements that are gyro based. These may include yawmeasurements which indicate the rate at which the associated vehicle isturning, longitudinal acceleration measurements, etc. Gyros often havean inherent measurement error referred to as a gyro bias that can affectmeasurements. The gyro bias estimator 277 estimates such biases to allowthe gap controller to compensate for such gyro based measurement errors.

The platoon controller 110 can include any other estimators 279 that maybe useful to any particular gap controller 112 as well.

The platoon controller 110 may also include one or more trackers 116.Each tracker 116 is arranged to measure or otherwise determine the gap.One type of tracker that is used in many implementations is a radarbased radar tracker 283. Newer commercially available trucks often comeequipped with a radar unit as standard equipment and radar trackers areparticularly well suited for use in such vehicles. Of course, one ormore radar units may be installed on any vehicle that does not comepre-equipped with a radar unit to facilitate use of radar tracker 283.By way of example, some specific radar trackers are described in moredetail in co-pending U.S. application Ser. Nos. 15/590,715 and15/590,803, both filed May 9, 2017, both of which are incorporatedherein by reference.

LIDAR is another distance measuring technology that is well suited formeasuring the gap between vehicles. LIDAR is quickly gaining popularityfor use in automated and autonomous driving applications. LIDAR tracker286 is well suited for use on vehicles that have or are provided withLIDAR units. Cameras and stereo cameras are also becoming more populardistance measuring tools for use in various automated and autonomousdriving applications.

Of course, other distance measuring technologies can be used to measureor estimate the gap between vehicles as represented by other trackers289. By way of example, a GPS tracker could be used that is basedprimarily on the respective reported GPS positions of the vehicles.

The tracker(s) used in many embodiments are configured to fuse data frommultiple sensors to help validate the measurements of the primarysensors used by the respective trackers. The aforementioned radartracker application describes a variety of methods for fusing data tohelp validate measurements of a primary sensor in that manner.

In various embodiments, the gap estimator 240 could replace or bereplaced by one or more of the trackers, or could be thought of as atracker itself since it determines/estimates the gap based on inputsfrom multiple sensors. In the illustrated embodiment, the gap estimator240 is shown separately as part of gap controller 112 since it fusesdistance data from the tracker(s) and any other available sources suchas GNSS sensors on each of the vehicles.

The platoon controller 110 may also include one or more monitors 118that are configured to monitor specific components that are relevant togap control. By way of example, one specific monitor that isparticularly useful to the control of platooning trucks is brake healthmonitor 291. The brake health monitor 291 is configured to monitor thebrake system and to identify circumstances in which the brakes may notbe able to deliver the level of braking normally expected for platooncontrol—as for example could occur if the foundation brakes include drumbrakes that have been used while traveling downhill in the mountains tothe extent that they are close to overheating. If the brake healthmonitor 291 identifies such a circumstance, it informs the platooncontroller, which can take the appropriate remedial action. Theappropriate remedial action will vary based on the specificcircumstances identified by the brake health monitor, but may include,for example, actions such as dissolving the platoon, increasing thetarget gap to a level more appropriate for the brake conditions, etc. Ofcourse, the brake health monitor can also configured to identifycircumstances in which the condition of the brakes has improved (e.g.,the brakes have cooled sufficiently) and inform the platoon controllerof those circumstances as well so that the platoon controller can actaccordingly. For example, improved braking status may allow the targetgap to be reduced, a platoon to be reestablished or other appropriateactions.

The platoon controller may include any of a variety of other monitors299 that are configured to monitor the state or status of othercomponents, systems, environmental conditions, road or trafficconditions, etc. that may be relevant to platoon control. For example, aDSRC link monitor may be provided to monitor the status of a DSRCcommunication link between the platoon partners.

Referring next to FIG. 3, another embodiment of gap controller 112 willbe described in more detail. Similarly to the embodiment illustrated inFIG. 2, the gap controller 112 includes a target and state setter 200, agap regulator 210 and a gap estimator 240. In the embodiment of FIG. 3,the target and state setter 200 includes an operating state selector203, and a control parameter selector 206 that determines, selects, setsor otherwise indicates to the gap regulator the values of any variablecontrol parameters that are appropriate for use in the selectedoperational mode.

The operating state selector 203 is arranged to determine the intendedoperational mode (state) of the gap regulator 210. In some specificembodiments, the operational modes might include a “normal” or “gapcontrol” operational mode in which the gap regulator is configured tocontrol towards attaining an maintaining a designated gap between thevehicles. In the gap control operational mode control parametervariables dictated by the control parameter selector might include thetarget gap itself (e.g. 10 m, 12 m, etc.)—which may vary somewhat basedon driving conditions (e.g., weather, terrain, road conditions, traffic,etc.). Other control parameters during normal operation may includeparameters that impact the draw-in speed, the tightness of the control,tolerances or variations between torque control and braking control,etc. In other embodiments, “initiate platoon” and/or “draw-in” or“pull-in” may be one or more separate states that are used to establisha platoon and/or to bring the platoon partners together in a safe mannerunder at least partially automated control.

Another potential operational mode is a “dissolve” mode in which theplatoon controller transitions the trailing vehicle toward/to a positionat which the driver of the trailing vehicle (or an automatic cruisecontrol system) can safely take over control of the vehicle. Generally,dissolving a platoon includes increasing the gap between the vehicles ina controlled manner to/towards a point at which the platoon can bedissolved and vehicle control can be safely transferred to manualcontrol by the driver or to control through the use of a differentsystem such as adaptive cruise control. The dissolve mode may optionallybe triggered by a wide variety of different circumstances, as forexample, in response to one of the platoon partners or the NOC decidingto terminate the platoon; the detection of a car cutting-in between theplatooning vehicles; the loss of communications between the vehicles foran extended period; the detection of an object in front of the leadvehicle that is too slow or too close to the platoon; etc.

Another potential operational mode may be a velocity control or relativevelocity control mode. Velocity control, or relative velocity controlmay be preferable to trying to control to maintain a particular gap in avariety of specific circumstances—as for example when the trailingvehicle's radar (or other) tracking unit loses sight of the partnervehicle, as can occur when there is a lateral offset between thevehicles due to a lane change or other conditions.

Of course, there can be a variety of other operational modes as well.

The gap regulator 210 is arranged to control the trailing platoonpartner in the manner designated by the target and state setter 200. Inthe embodiment illustrated in FIG. 3, the gap regulator 210 includes ascaler 212 and two separate controllers which are used in differentcombinations in different operating modes. In the illustratedembodiment, the controllers include a sliding mode controller 215 (whichperforms gap control) and a velocity/relative velocity controller 218.It should be appreciated that in other embodiments, a single controller,additional and/or different may be provided as appropriate for anyparticular implementation.

In the illustrated embodiment, the feed forward scaler 212 is configuredto scale the torque and brake signals from the front vehicle beforeadding them to the outputs from the sliding mode and relative velocitycontrollers 215, 218 to create the torque and brake request to theengine and brake controllers. Such scaling may be based on factors suchas the respective weights (masses) of the platoon partners, therespective drags of the vehicles, the severity of a braking event (e.g.,in high braking scenarios, the braking command may be increased a bit toprovide a margin of safety to account for uncertainties in brakingperformance and reactions times), etc. In other embodiments, suchscaling functions can be integrated into the respective controllersthemselves if desired.

The sliding mode controller 215 is configured to control the trailingvehicle in a manner that seeks to attain and maintain the desired gap inaccordance with the target gap and any other control parametersspecified by the control parameter selector 206. Thus, its primaryfunction is gap control. The velocity controller 218 is configured tocontrol the trailing vehicles in a manner that maintains a designatedvelocity relative to the lead vehicle, or in some circumstances, simplya designated velocity. In the illustrated embodiment, these two separatecontrollers are provided so that the gap regulator 210 can providedifferent types of control, as may be appropriate in differentoperational circumstances. A few specific examples are described withreference to FIGS. 4A-4C. In the described embodiments, both thecontrollers 215 and 218 are operated continuously during platooning andthe selector/adder 250 is used to select the appropriate signals tooutput based on the current operating mode. An optional braking monitor255 is a safety feature that may be utilized to help ensure that thebrake commands outputted by selector/adder 250 don't overly aggressivelybrake the trailing vehicle except in where necessary from a safety/crashprevention standpoint. This is to reduce the risk of traffic behind thetrailing platoon partner from being impacted by unexpected aggressivebraking of the trailing platoon partner.

The sliding mode controller 215 is arranged to control the trailingvehicle in a manner such that its relative velocity relative to thefront vehicle varies as a function of the gap between the vehicles. Thischaracteristic is illustrated in the state space diagrams of FIG. 5which show a control scheme in accordance with one specificimplementation. More specifically, FIG. 5 plots relative velocitybetween the vehicles (the Y-axis) vs. gap between the vehicles (theX-axis). FIG. 5 also show a torque request controller target controlline 320. In the illustrated embodiment, the nominal desired gap is 12meters—which is represented by line 310. Thus, the target control point311 is 12 meters with zero relative velocity, which is the pointrepresented by the intersection of line 310 (12 meters gap) and line 312(zero relative velocity).

The torque request controller component 221 of gap regulator 210 isconfigured to generate a torque request that is appropriate to controlthe gap in accordance with target control line 320. The torque requestis then implemented by engine torque controller 152. As can be seen inFIG. 5, when the gap is larger than the desired gap, the rear truck iscontrolled to travel slightly faster than the front truck is travelingsuch that the relative velocity of the rear truck has a small positivevalue. As the rear truck draws closer to the lead truck, its relativevelocity is reduced in a smooth manner until the gap is reduced to thetarget control point 311, at which point the relative velocity would bezero if perfect control were attained. If the rear truck gets closerthan the desired gap, it is slowed so that it has a negative relativevelocity relative to the lead truck to reestablish the desired gap.

The sliding mode controller 215 utilizes a unified sliding mode controlscheme during both the “pull-in” and gap maintenance stages ofplatooning. Configuring the sliding mode controller to control towardstarget control line 320 helps ensure that the relative speed vs. gaprelationship stays within a region safe for platooning.

In the embodiment illustrated in FIG. 3, the sliding mode controller 215includes separate controllers (e.g. torque request controller 221 andbrake request generator components 223) which are configured to controltowards different gap control targets. The different control targets areillustrated in the state space diagrams of FIG. 5 which show a controlscheme in accordance with one specific implementation. Morespecifically, FIG. 5 shows a brake request controller target controlline 330 in addition to torque request controller target control line320. FIG. 5 additionally shows representative transition paths fromvarious points in the state space to the torque request target controlline 320.

For most open highway driving conditions, modulating the torque requestalone is sufficient to control the gap appropriately without requiringthe use of the foundation brakes. This is in part because the torquerequest can be negative to a certain degree without needing to actuatethe foundation brakes through the use of engine braking and/or theretarder (if available). As mentioned above, when fuel is cut-off therewill be some pumping losses and some frictional losses in thepowertrain, so some level of negative torque can be provided while usingnormal valve timing by simply reducing the fuel charge appropriately.When larger negative torque is needed, the engine torque controller 152can create larger negative torques by actuating the retarder and/or bytaking other appropriate measures.

Separately, the brake request controller component 223 of gap regulator210 is arranged to generate brake requests during normal operation thatare generally arranged to maintain a different gap—specifically asmaller gap—than the torque request controller 221 targets. Thisdifference in the gaps that the torque and brake request controllerscontrol to is sometimes referred to herein as the gap tolerance 340. Ingeneral, brake requests 213 are not generated unless or until the gap isreduced at least the gap tolerance below the torque request targetcontrol line 320. Since the brakes can only be used to slow the vehicle,the effect of this difference is that the trailing truck will be allowedto creep in a relatively small amount (2 meters in the example) beforethe foundation brakes are actuated when the gap regulator 210 cannotmaintain the desired gap through control of the torque request alone.When the desired gap can be restored by modulating the torque requestsalone without crossing target brake control line 330, then thefoundation brakes do not need to be used at all. This has the effect ofsafely maintaining a gap while reducing the probability that thefoundation brakes will be deployed unnecessarily.

Normal gap control is illustrated in FIG. 4A. During normal gap control,the sliding mode controller 215 is use to determine torque and brakerequests that are appropriate to attain and maintain the target gap setby control parameter selector 206. When appropriate, the torque andbrake requests generated by the sliding mode controller 215 may bescaled appropriately by selector/adder 250 based on inputs from feedforward scaler 212. In this normal gap control mode, the outputs of therelative velocity controller 218 are not used in the control of thetrailing vehicle.

In some embodiments, the sliding mode controller 215 includes separatetorque request and brake request controllers 221, 223 as illustrated inFIG. 3. The torque request and brake request controllers 221, 223 areconfigured to control the engine and brakes respectively towardsdifferent gap targets which tends to provide a smoother, morecomfortable ride and reduce the use of wheel brakes (e.g., thefoundation brakes in tractor-trailer rigs) compared to control in whichthe engine and brakes are controlled to the same target gap. Such a gapcontrol architecture is described in more detail in U.S. Provisionalapplication No. 62/489,662, which is incorporated herein by reference.

Although the sliding mode controller 215 works very well to control thegap, there will be operational circumstances in which different types ofcontrol may be appropriate. For example, a different type of control maybe desirable when it is necessary to dissolve a platoon and return thetrailing vehicle to manual or other automated control. Typically, thegap between vehicles during platooning will be smaller, often muchsmaller, than can safely be maintained by a driver under manual control.Therefore, in general, when a platoon is dissolved with the intent torestoring manual control of the trailing vehicle, it will be desirableto grow the gap to a distance that is appropriate for manual controlbefore relinquishing control to the driver. This can be accomplished ina smooth manner by relative velocity controller 218.

When operating state selector 203 determines that the platoon should bedissolved, it directs the GAP regulator 210 to transition to a dissolvemode as represented by FIG. 4B. In the dissolve mode, primary control isprovided by relative velocity controller 218. The control parameterselector 206 may designate a desired (target) relative velocity for thetrailing truck during the dissolve. The specific target relativevelocity may vary based on the nature of the circumstances and/or thevehicles involved in the platoon. In general, it is desirable to selecta relative velocity that will cause the vehicles to gradually, butexpeditiously separate, without requiring the trailing vehicle to slowexcessively (which could unduly hinder following traffic) and preferablywithout requiring the lead vehicle to alter its drive plan. By way ofexample, relative velocities during dissolves on the order of 0.5 to 4meters per second, as for example, 1-2 m/s, have been found to work wellin the context of platooning trucks.

During a dissolve, the lead vehicle may take a variety of actions. Forexample, the lead truck may accelerate or increase its torque commandaggressively. In such cases, it may not be desirable to try toaccelerate the trailing truck in a similar manner thereby allowing thelead vehicle to pull away more than would otherwise occur under relativevelocity control. One way to accomplish this in the context ofplatooning trucks is to ignore or otherwise disable positive torquecommands from feed forward scaler 212.

Another potential scenario is that the lead truck brakes or slowssignificantly while under velocity control. In some circumstances, thevelocity controller 218 may be configured to permit a certain amount ofgap shrinkage when the gap is relatively larger to thereby reduce theoverall amount of braking required. In the illustrated embodiment, thesliding mode controller is configured to ensure that the gap between thevehicles is always sufficient to give the trailing vehicle sufficienttime to respond in a manner that prevents the trailing vehicle fromrunning into the back of the lead vehicle regardless of the occurrenceof (reasonable) unexpected events. Therefore, if the sliding modecontroller is outputting a braking or negative torque signal that has agreater magnitude than the relative velocity controller, then thatlarger braking/negative torque command should be passed to the vehicle'sengine and braking controllers. Therefore, during a dissolve, theselector/adder 250 is configured to only utilize negative commands(i.e., braking commands and negative torque commands) from the slidingmode controller 215 and to only use such commands when they are greaterin magnitude than the commands from the relative velocity controller218.

There may also be operational circumstances outside of dissolves inwhich relative velocity control or simply velocity control is desired.For example, there may be circumstances in which the back of the leadvehicle moves out of view of the trailing vehicle's tracker(s) 116 orthe tracker(s) 116 otherwise loses sight of the back of the platoonpartner. This can occur, for example, as a result of a lane change byone of the platoon partners. In such a circumstance the gap regulatormay not have an accurate measure of the longitudinal gap between thevehicles—and may have to rely on less accurate approaches fordetermining the gap such as the vehicle's respective GNSS positions. Insuch circumstances, it may be desirable to control the trailing vehicleto slowly drop back until the back of the lead vehicle comes within thetracker's view. Again, the relative velocity controller 218 is wellsuited for use in this circumstance—although the preferred relativevelocity control may be a bit different than occurs during a dissolve.Specifically, the goal is typically not to drop back as quickly or asfar as would occur during a dissolve—thus a smaller relative velocity(e.g. 0.5 m/s vs. 2 m/s), may be appropriate.

One approach to such relative velocity control is illustrated in FIG.4C. In the velocity control scheme of FIG. 4C velocity controller 218 isused in conjunction with normal scaling from feed forward scaler 212.This causes the trailing platoon partner to better follow lead vehicleaccelerations and/or torque increases than occurs during the dissolvestate illustrated in FIG. 4B. At the same time, for safety purposes,braking requests and negative torque request from the sliding modecontroller 215 may be utilized as appropriate by selector/adder 250 in amanner similar to the approach described above with respect to FIG. 4B.

Although particular platoon and gap controller architectures areillustrated in FIGS. 2 and 3, it should be appreciated that the specificarchitectures utilized may vary widely to meet the needs of anyparticular platooning or other automated vehicle control scheme.

As will be apparent to those familiar with the art, the describedcontrollers can be implemented algorithmically using software orfirmware algorithms executing on one or more processors, usingprogrammable logic, using digital or analog components or using anycombination of the preceding.

In the detailed description above, it is assumed that the controlledpower plant is an internal combustion engine, as for example a dieselengine. However, it should be appreciated that the described controlapproach can be utilized regardless of the nature of the power plantused to provide torque to drive the host vehicle. Thus, the describedcontroller design, functionalities and architectures may generally beapplied to the control of vehicles that utilize electric motors,turbines, fuel cells, or other types of powerplants to provide power toa drivetrain or directly to one or more wheels, including hybrids whichcombine more than one type of powerplant (e.g., hybrids that incorporateboth an electric motor and an internal combustion engine). When thepower plant is or includes an internal combustion engine, any type ofinternal combustion engine may be used including gas powered engines,diesel powered engines, two-stroke engines, 4-stroke engines, variablestroke engines, engines utilizing more than four-strokes, rotaryengines, turbine engines, etc.

The description above has focused primarily on tractor-trailer truckplatooning applications, however, it should be appreciated that thedescribed control approach are well suited for use in a wide variety ofconnected vehicle applications, regardless of whether one or more of thevehicles involved have 2, 3, 4, 18 or any other number of wheels, andregardless of nature of the powerplants used in such vehicle.

FIG. 6 illustrates a platoon control system hardware architecture thatis particularly well suited suitable for ASIL compliant platoon control.The illustrated embodiment includes three separate controller hardwareunits. These include platoon controller 410, vehicle interfacecontroller 460 and gateway processor 470. Selected components of arepresentative gateway processor 470 are illustrated in FIG. 7. As bestseen in FIG. 6, the platoon controller 410 communicates with the vehicleinterface controller 460 through an interface 420 and with gateway 470through a direct link 478. In some embodiments, the link 478 is adedicated direct wired connection and no other devices are coupled tothat link. The wired connection may be provided by any suitable form ofcabling or traces, as for example co-ax cable, twisted pair wirings,fiber optics or any other suitable physical connection medium.

In the illustrated embodiment, the platoon controller 410 incorporatesall of the functionality of platoon controller 110 described above. Thevehicle interface controller 460 (also sometimes referred to as a systemmanager) performs the functionality of actuator interface 160 andfurther includes a number of safety monitors. In some embodiments, thesafety monitors are arranged to execute ASIL compliant safety monitoringalgorithms and the vehicle interface controller 460 is designed as anASIL compliant device.

In general, the vehicle interface controller 460 includes a highersafety level processor and software (including the safety monitors) thatindependently verifies the commands transmitted by the platooncontroller 110 before they are passed on to the vehicle actuators. Theseverifications use a subset of the available sensor inputs, together withverification algorithms that are independent and distinct from thoseused by the platoon controller.

The gateway processor 470 is arranged to coordinate communicationsbetween a host vehicle and the platoon partner(s) and to coordinatecommunication between the host and the network operation center and/orany other entities that are external to the vehicle. As such, in aspecific implementation of the system illustrated in FIG. 1 the gatewayprocessor 470 includes the inter-vehicle communications controller 170and NOC communication controller 180 as best illustrated in FIG. 7.Typically the inter-vehicle communications controller utilizes ashort-range, vehicle-to-vehicle wireless communications protocol, as forexample the DSRC protocol. The NOC communication controller typicallycommunicates with a networks operations center using cellular orsatellite communications.

In some embodiments, the connection (link 478) between the gatewayprocessor 470 and the platoon controller 410 is a dedicated direct wiredconnection and no other devices are coupled to the link. In someimplementations an Ethernet or similar standardized wired communicationsprotocol is used to pass information between the gateway processor andthe platoon controller. This facilitates high speed, high reliabilitycommunications between the gateway processor and the platoon controller.In a specific example, a 100BASE or higher (e.g. 1000BASE, 10GBASE,etc.) Ethernet physical layer may be used, although it should beappreciated that a variety of other physical layers may be used in otherembodiments.

In some embodiments, the gateway processor 470 is also arranged tocommunicate with a forward facing camera 477 mounted on the vehicle anda dashboard display 475. When the host vehicle is the lead vehicle in aplatoon, the gateway processor transmits a video feed received from theforward facing camera 477 to the trailing vehicle(s) so that the driverof the trailing vehicle has a view of what is in front of the leadvehicle. When the host vehicle is a trailing vehicle in the platoon, thegateway processor 470 receives such a video feed from the gatewayprocessor on the lead vehicle and transmits the feed to the dashboarddisplay 475 where it is displayed to give the driver of the host vehiclea view of what is in front of the lead vehicle. Displaying a view ofwhat is in front of the lead vehicle to drivers of a trailing vehicle isdesirable to provide the driver of the trailing vehicle with improvedsituational awareness and the ability to independently react tosituations that occur in front of the platoon. This can be particularlyimportant because in many platoons (e.g. platoons that involve tractortrailer trucks) the trailing vehicle will be very close to the leadvehicle (much closer than normal manual driving) and the lead vehiclewill effectively block the view of the trailing vehicle which can be anuncomfortable experience for drivers and/or passengers in a trailingplatoon partner—especially when they do not have access to a view ofwhat is going on in front of the platoon.

The video streams passed through the gateway may be managed by a videomanager 474. Since the gateway 470 communicates directly with the camera477 and/or dashboard display 475, the platoon controller 410 is not inany way burdened by the need to manage that data flow.

In some embodiments the gateway 470 also includes a message logger 473that logs various messages and other information passed there through inorder to provide a record for diagnostic purposes and the like. Thefunctionality of the message logger 473 will be described in more detailbelow.

The platoon controller 410 is configured as a listener on anyappropriate vehicle communications buses where it can directly obtaininformation about the vehicle's operational state—such as the vehicle'scurrent wheel speed, any brake or accelerator pedal inputs, steeringwheel position (as appropriate), transmission gear, etc. It is alsocoupled to sensor units such as GPS unit 131 to receive positionalinformation about the location of the vehicle, and to forward lookingradar unit 137 to receive information about the position of objectsoutside the vehicle (e.g., radar scenes). Similar information may beobtained from other sensors as well, such as LIDAR 138, camera(s) 139etc. Since the platoon controller 410 is configured strictly as alistener on the vehicle's communication bus(es) and does not itselftransmit information over such bus(es), it does not need to be ASILcompliant, as long as the control commands it outputs to the vehicleinterface controller are verified to ASIL standards by the vehicleinterface controller 460.

The vehicle interface controller 460 (also sometimes referred to as thesystem manager 460), which is ASIL compliant, is arranged to sendcommands to, and otherwise communicate with, the vehicle's enginecontroller (EECU), the brake controller (BECU), and/or any otherappropriate controllers either directly or via one or morecommunications buses, such as the vehicle's CAN bus(es).

In the illustrated embodiment, the interface 420 between platooncontroller 410 and vehicle interface controller 460 (also sometimesreferred to as the system manager 460) is fairly narrowly defined. Itincludes the substantive commands generated by the platooncontroller—which in the illustrated embodiment include torque request422, brake request 424, and optionally a retarder request 426. When theplatoon controller also controls the steering or other aspects of thehost vehicle steering and/or other appropriate control commands (notshown) may be included as well.

The interface 420 also includes a platooning state indicator 428 that isa signal from the platoon controller indicating whether or not itbelieves that its output should be directing operation of the vehicle.The platooning state indicator 428 may take many forms, as for example asimple flag that when high indicates that the platoon controller 410believes that platooning is/should be active and that its torque,braking and retard commands 422, 424, 426 should be followed. In such anarrangement, a low flag state indicates that the platoon controllerbelieves that it is not controlling the vehicle. The vehicle interfacecontroller 460 does not forward any torque, braking, retard or othercontrol commands at any time that the platooning state indicator 428indicates that platoon control is not active. In the event (generallyunlikely) that one of the safety monitors 465 indicates that platooningis not appropriate when the platoon controller 410 believes thatplatooning is valid (as indicated by platooning state indicator 428),the vehicle interface controller/system manager 460 initiates atermination of the platoon.

The interface 420 also facilitates the transmission of certain stateinformation—which is preferably ASIL validated state information—aboutboth the host vehicle and the partner truck that is useful to the safetymonitors. Specifically, the host vehicle state information 441 includesstate information about the host vehicle that has been validated (e.g.,ASIL-C validated) by the system manager 460 and is useful to one or moresafety monitors on the partner vehicle. The partner vehicle stateinformation 444 includes state information about the partner vehiclethat has been validated by the partner vehicle's system manager and isuseful for one or more safety monitors 465 on the host vehicle. Hostvehicle state information 441 is transmitted to the platoon controller410, which forwards such information without modification to the gateway470, which in turn forwards the host vehicle state information to thegateway on the partner vehicle. Partner vehicle state information 444received by gateway 470 from the partner vehicle's gateway is forwardedwithout modification to the platoon controller 410 and from there tosystem manager 460 (again without modification). Preferably the hoststate information 441 is transmitted with a checksum or other suitabledata integrity verification mechanism that allows the receiving systemmanager to verify that the data it receives is uncorrupted. Anycorrupted information can then be ignored. With this approach the ASILvalidated state information is passed without modification from one ASILcompliant device (system manager 460 on a first platoon partner) toanother (system manager 460 on a second platoon partner) and thereforeis suitable for use in ASIL compliant safety checking algorithms—evenwhen intermediate transmitting devices (e.g., platoon controller 410,gateway 470) are not themselves ASIL compliant.

The host and partner vehicle state information may include any ASILvalidated state information that is used by any of the safety monitors.This may include, for example, vehicle wheel speeds, brake requests,torque requests and/or delivered torque, brake air supply pressure,steering position, accelerometer readings and/or any other informationabout the partner vehicle used by the system manager 460 as part of asafety monitor. To the extent that the platoon controller 410 utilizespartner state information originated by an ASIL validated device beyondthe state information used by the system manager 460, that informationcan optionally be included in the vehicle state information 441, 444 aswell—although such inclusion is not necessary and usually not desirablesince such information can typically be obtained and sent by the partnervehicle's platoon controller, which reduces the bandwidth that needs tobe allocated to the interface 420.

It is noted that some of the host vehicle's sensor information (e.g.,wheel speed, brake pedal position, radar scenes, etc) is used by boththe platoon controller 410 and the system manager 460. Since the platooncontroller 410 is preferably an authorized listener on any appropriatevehicle control bus(es), the platoon controller does not need to wait toreceive such information from the system manager. Rather, it obtains anyrelevant host vehicle sensor information directly from the appropriatesensor over any suitable connection such as an appropriate CAN bus.However any sensor information relevant to the system manager on thepartner vehicle is read by the system manager (regardless of whether itis also read by the platoon controller) and included in host vehiclestate information 441 so that the partner vehicle's system manager isensured that such information is ASIL verified. In other embodiments anyhost vehicle sensor information that is not directly accessible by theplatoon controller can be received via the system manager 460 acting asan intermediary.

Although there will be some overlap in the sensor information used, itshould be appreciated that the host vehicle sensor information used bythe host vehicle platoon controller 410 and the host vehicle systemmanager 460 will often vary and may further vary from the partnervehicle sensor information of interest. For example, the host platooncontroller utilizes GNSS position data in the determination of thetorque and braking requests, however the GNSS position information maynot be utilized by the System Manager since it is not ASIL compliant.

Some of the sensor information that is used by the safety monitor on thehost vehicle may not be needed by the safety monitor on the partnervehicle. This may include information such as the radar scenes, theaccelerator pedal position, inputs from a host vehicle driver interfacedevice 469, etc. To the extent that such sensor information is not usedby the partner vehicle, there is no need for such information to beincluded in the vehicle state information 441, 444.

Some of a host vehicle's sensor information that is used by the platooncontroller on the partner vehicle may not be ASIL compliant andtherefore may not be used in the safety monitors on the partner vehicle.Such, sensor information that is not relevant to the safety monitors onthe partner vehicle does not need to be included as part of vehiclestate information 441, 444. Rather, such data may be obtained by theplatoon controller 410 and sent to the corresponding platoon controlleron the partner vehicle (by way of communication controllers 470). Forexample, it is extremely difficult to ASIL validate GPS or other GNSSposition data. Therefore, GNSS position data is preferably not includedin the vehicle state information 441, 444. Rather, such information ispassed from the host vehicle's platoon controller to the partnervehicle's platoon controller via the gateways 470.

The driver interface device 469 may be a button or other suitablemechanism positioned at a convenient location on the host vehicledashboard or elsewhere in the host vehicle cabin. The driver interfacedevice 469 is a mechanism that the driver may press as appropriate toindicate that the driver is ready to platoon during initiation of aplatoon, or to initiate the dissolution of a platoon when platooning isno longer desired. The use of the driver interface device 469 isdescribed in more detail in U.S. patent application Ser. No. 15/607,902which is incorporated herein by reference. In the illustratedembodiment, commands from the driver interface device 469 (which arepreferably ASIL compliant) are sent to the vehicle interface controller460 and passed from there to the platoon controller 410. Similarly,requests to the driver interface device pass from the platoon controllerto the vehicle interface controller 460 and from the vehicle interfacecontroller 460 to the driver interface device 469. This architecturesimplifies the work that must be done to make the driver interfacedevice 469 ASIL compliant. It should be appreciated, however, that inother embodiments, the platoon controller 410 may also be a directlistener to commands from the driver interface device. In the embodimentillustrated in FIG. 6, interface 420 includes driver platoon relatedrequests and commands 427 which represent the request sent to andcommands received from the driver interface device 469.

In some specific embodiments, the vehicle interface controller 460 isimplemented as a single dedicated integrated circuit chip and theplatoon controller 410 and gateway processor 470 are each implemented asseparate system on modules (SOMs).

The platoon control system hardware architecture illustrated in FIG. 6is particularly well suited for efficiently handling platooning controlrelated tasks in an ASIL compliant manner using information availablefrom a variety of sources including sources that are not themselvesASIL. With the described arrangement, the powertrain control commandsultimately issued by the control system may be ASIL rated.

The hardware architecture of FIG. 6 also has several advantages from asecurity standpoint. In the illustrated embodiment, the gatewayprocessor 470 is not connected to any of the vehicle's control relatedcommunications buses (e.g., the CAN bus(es)). Therefore, the gatewayprocessor 470, which is potentially the least secure of the threehardware components, is not able to transmit any information directlyonto any of the more secure vehicle communications buses or receive anyinformation directly from such buses—which is advantageous from asecurity standpoint since a nefarious entity cannot gain control thevehicle in any way by somehow hacking into the gateway processor 470.Furthermore, with this arrangement, the gateway processor 470 does notneed to be ASIL compliant which greatly simplifies its certification.

System and Method for Mitigating or Avoiding Risks Due to HazardsEncountered by Platooning Vehicles

During the course of driving, a road obstacle or other hazard may causea lead vehicle in a platoon to react and take action to avoid risksassociated with the hazard. Under such circumstances, the lead vehiclereacting before the following vehicle often increases risks. Forexample, if the lead vehicle brakes before the following vehicle, in aworst case scenario, it is conceivable that the following vehicle maycollide with the leading vehicle.

Such problems caused by road obstacles or hazards are avoided ormitigated by (1) receiving data generated by one or more sensorsarranged to interrogate a space radially extending from the lead vehicleas the lead vehicle travels over the road surface, (2) ascertaining ahazard caused by an object in the space from the data indicative of theperceived environment and (3) causing the following vehicle, whileoperating in the platoon, to take a preemptive action to avoid ormitigate risks resulting from the hazard caused by the object in thespace, the preemptive action taken by the following vehicle prior toand/or without waiting for the lead vehicle taking any action inresponse to the object in the space. For example, by slowing thefollowing vehicle before the lead vehicle, it has been the incidence ofcollision between the platooning vehicles is significantly reduced.

While scenario above describes a situation of hazard avoidance, itshould be understood that present invention is directed to a boarderconcept. For instance, the present application is should be construed asaddressing the general concept of using sensor data collected orgenerated by one vehicle in a platoon to control the operation ofanother vehicle in the platoon. Typically, the data is used by thereceiving vehicle to avoid hazardous conditions or other risks. However,this is by no means a requirement. On the contrary, the data can be usedby the receiving vehicle for just about any purpose.

Referring to FIG. 8, a diagram 800 showing a platoon including a leadvehicle 802 and several following vehicle(s) 804 encountering a hazard,represented by an object 806, while traveling across a road surface isillustrated. As the vehicles are operating in a platoon, a gap 808 isprovided and controlled between any pair of leading and following trucksas described in detail above.

The lead vehicle 802 includes one or more sensors (not illustrated inFIG. 8) that are used to interrogate a space, designated by referencenumeral 810. In this particular embodiment shown, the space 810 extendsradially outward from the front of the vehicle 802, encompassing theroad ahead. It should be understood, however, that the particulardirection and shape of the space 810 as depicted is by no meanslimiting. On the contrary, the space 810 in various embodiments canradiate outward from the front, side(s) rear, 360 degrees or anyfraction thereof, around the lead vehicle 802. Thus, the space 810,which is interrogated by the aforementioned sensor(s), should be widelyconstrued to cover any applicable shape or direction.

As the platoon travels down the road surface, the sensor(s) on the leadvehicle 802 generate data indicative of the perceived environment withinthe space 810. As a result, a hazard caused by the presence of anobstacle, such as object 806, may be ascertained. In variousembodiments, the object 806 represents a wide variety of potentialobstacles, such as other vehicles (e.g., cars, trucks, motorcycles),pedestrians, a cyclist, road debris, traffic signs or posts along theside of the road, or just about any other possible obstruction that maybe encountered while driving.

The Applicant has found that with platooning vehicles in non-emergencysituations, risks associated with hazards, such as created by anobstacle 806, are often mitigated or altogether avoided by directing thefollowing vehicle 804 to take a preemptive action prior and/or withoutwaiting for the lead vehicle 802 to react to the obstacle. For example,if the platoon crests a hill on a highway and suddenly encountersstopped cars (e.g., objects 806 that represents a hazard) ahead on thehighway, then the following vehicle 804 preferably brakes or takes someother preemptive action to slow down before the lead vehicle 802 slowsdown. By braking earlier, the rate at which following vehicle losesvelocity is greater than the lead vehicle. As a result, the gap 808between the two vehicles increases, potentially dissolving the platoon.The likelihood that the following vehicle 804 colliding with the leadingvehicle 802 is therefore significantly reduced.

In various implementations, the processing of the data generated by thesensor(s) on the lead vehicle, indicative of the perceived environmentwithin the space 810, may be performed either on the following vehicle804 or the lead vehicle 802. Two such embodiments are described below.

Referring to FIGS. 9A-9C, a set of block diagrams illustrating a firstembodiment of a risk mitigation or avoidance system 900 is illustrated.In this embodiment, the processing of the sensor data collected on thelead vehicle 802 is mostly performed by the following vehicle 804.

As illustrated in FIG. 9A, the lead vehicle 802 generates and collectsthe data from the sensor(s) and then transmits or relays the data in rawor generally non-processed form to the following vehicle 804. Inresponse, the following vehicle 804 perceives from the data theenvironment in the space 810 ahead of the lead vehicle 802, includingthe presence of an obstacle 806 that may represent a hazard. If a hazardis detected, one of a plurality of tiered severity threat levels isselected, depending on the severity of the hazard created by theobstacle 806. The following vehicle then implements one or morepreemptive actions, as dictated by the selected severity threat level,to avoid or mitigate the risks created by the object.

In FIG. 9B, a block diagram of the modules provided in the lead vehicle802 for generating, collecting and relaying the data to the followingvehicle 804 is illustrated. In particular, the lead vehicle 802 includesone or more sensor(s) 902, a platoon controller, such as the controllers110 and/or 410 as described above, and the gateway 470 for transmittingor relaying the data to the following vehicle 804.

As the lead vehicle 802 travels down the road surface, the sensor(s) 902interrogate the space 810, detecting any object(s) 806. The data fromthe sensor(s) 902, which can be used to perceive the environment withinthe space 810, is then transmitted to the following vehicle 804 via thegateway 470.

In various embodiments, the sensor(s) 902 may include one or more of aradar detection system, a Lidar or laser detection system, a camera orimaging system, a radio system, an automated braking system, anautomated collision avoidance system, a GPS system, a cruise controlsystem, or any other type of passive sensor (e.g., a sensor that doesnot transmit signals but rather is required to perform a measurement,such as a camera) or active sensors such similar radar, Lidar and/orultrasound, or any combination thereof. In addition, the sensor(s) 902also includes “sensors’ that require some type of hardware on the sensesobject, such as ultra-wideband, where an antenna is needed on the sensedvehicle. As each of these types of sensor(s) and their use on vehiclesis well known, a further description is not provided herein for the sakeof brevity.

The sensors 902 do not necessarily have to be physically provided on thelead vehicle 802. In alternative embodiments, the sensors 902 can alsobe various types of road-side sensors, such as but not limited to acamera, a traffic speed monitor or camera, a precipitation monitor, atemperature monitor, a wind sensor, a humidity sensor, a trafficmonitoring sensor, or an in-ground sensor. As such, the term “sensor” asused herein should be broadly construed and is intended to mean bothsensors onboard a vehicle, road-side sensors, or possibly a combinationof both.

Referring to FIG. 9C, a diagram illustrating the modules for receiving,processing and implementing preemptive action(s) on the followingvehicle 804 are illustrated. The following vehicle 804 includes agateway 470 for receiving the data transmitted by lead vehicle 802, athreat level determination module 904, an action implementation module906, platoon controller 110 and/or 410, and optionally a machinelearning module 908.

As described above, the platoon controller 110 and/or 410 on thefollowing vehicle 804 operates to maintain the gap 808 with the leadvehicle. As the platoon travels down the road surface, the module 904processes the data received over the gateway 470. From the data, themodule 904 can perceive the environment in the space 810 ahead of thelead truck 802 and ascertain any possible hazards created by one or moreobjects 806 that may be detected.

In the event any detected object(s) 806 represent a threat, then inaccordance with a non-exclusive embodiment, the module 904 may selectone of a plurality of tiered severity threat level thresholds orthresholds, each defining one or more corresponding preemptive action(s)respectively. In other words, the module 904 selects an appropriate oneof the tiered threat levels commensurate with the severity of the threatrepresented by a perceived object 806.

The action implementation module 906 operates in cooperation with thethreat level determination module 904. The module 906 is responsible forimplementing specific preemptive action(s) that correspond to theselected severity threat level, as determined by the module 904, tomitigate or avoid the risks resulting from the object 806 in the space810. Such preemptive action(s) may include, but are not limited to,broad categories such warnings and/or alerts, certain precautionarypreparations in anticipation of a possible collision, and other specificactions.

In optional embodiments, machine learning module 908 operates incooperation with the threat level determination module 904 to identifyobjects 806 and ascertain the threat level they may represent. Machinelearning module 908 provides the ability to predict, learn and identifyparticular object(s) 806 that may be perceived in the field 810. Forinstance, module 908 may rely on image or pattern recognition andcomputational learning, artificial intelligence, along with dataanalytics and algorithms, to distinguish different types of objects(e.g., cars, buses, trucks, pedestrians, etc., and the particularsregarding each). Using image recognition, learning module 908 may beable to differentiate one type of vehicle versus another, whether or nota vehicle is moving or stationary (e.g., stalled on the road or moving),the direction a vehicle is travelling from the color of detected lights(e.g., white light from headlights indicates the vehicle is traveling inthe oncoming direction, whereas red or brake lights indicates thevehicle is traveling in the same direction), road debris, pedestrians,etc. By recognizing or defining an object 806, the level determinationmodule 904 can make a more accurate assessment of the perceived threat.If the object ahead is identified as a pedestrian, then the selectedthreat level is likely to be at an emergency level, meaning immediatepreemptive action is required to avoiding running over the person. Onthe other hand if the object 806 is identified as road debris, such as atire tread, then the selected threat level will likely be pre-warning ora non-emergency (i.e., a low threat), and the preemptive action willlikely be a mere warning.

Referring to FIGS. 10A-10C, a set of block diagrams illustrating asecond embodiment of a risk mitigation or avoidance system 1000 isillustrated. In this embodiment, the processing of the sensor datacollected on the lead vehicle 802 is mostly performed by the followingvehicle 804.

As illustrated in FIG. 10A, the lead vehicle 802 is responsible for (1)generating the data from the one or more sensor(s) 902, (2) perceivingif the environment in space 810 ahead of lead vehicle 802 includes anyobject(s) 806, (3) ascertaining any threat created by the object(s) 806and (4) selecting an appropriate tiered threat level threshold that iscommensurate with the severity of the threat represented by an object(s)806. In addition, the lead vehicle 802 generates and sends codedcommands to the following vehicle 804 that are indicative of thepreemptive actions to be taken as dictated by the selected severitylevel.

FIG. 10B illustrates the modules for generating and processing the datafrom the sensor(s) 902 on the leading vehicle 802. Specifically, thelead vehicle 802 includes sensor(s) 902, threat level detection module904, platoon controller 110 and/or 410, optionally machine learningmodule 908, and gateway 470. As each of these modules has beenpreviously discussed, another description is not repeated herein for thesake of brevity. In addition, the leading vehicle 802 includes anencoder module 910, which is responsible for encoding any preemptiveaction(s) defined by the module 904. The gateway 470 then transmits theencoded command signal(s) to the following vehicle 804.

FIG. 10C illustrates the modules for receiving and processing thecommand(s) on the following vehicle 804. The modules include gateway 407for receiving the command(s), a platoon controller 110 and/or 410, adecoder 912, and action implementation module 906. During use, thereceived command(s) are decoded by module 912 and provided to the module906. In response to the command(s), module 906 implements the definedpreemptive action.

In either of the above embodiments, the threat level detection module904 is responsible for selecting one of a plurality of tiered threatlevels or thresholds depending on the severity of the perceive threat.By way of example, a non-exclusive embodiment with four tiers isdescribed below. In alternative embodiments, the number of tiers maysignificantly vary from a few too many. As such, the specific tiers andthe corresponding preemptive actions as discussed below are exemplaryand should not be construed as limiting in any regard.

Referring to FIG. 11, a table including four severity threat levels isillustrated in accordance with a non-exclusive embodiment of theinvention. In this particular embodiment, the four severity levelsinclude:

-   -   (1) Pre-warning threat,    -   (2) Moderate security threat,    -   (3) High security threat, and    -   (4) Emergency security threat.

The table also includes three columns, each defining a category ofpreemptive actions. The three categories in this example include:

-   -   (1) Warning(s) and/or Alerts,    -   (2) Safety precautions in anticipation of a collision, and    -   (3) Specific actions.

Referring to FIG. 12, corresponding preemptive actions for each of thethree categories are listed. The corresponding preemptive actions foreach category include:

Warning(s)/Alert(s): flashing or operating warning lights on thefollowing vehicle, operating a horn on the following vehicle, operatingvisual warnings on the following vehicle, operating haptic actuators onthe following vehicle and/or manipulating a radio on the followingvehicle.

Safety Preparations: for braking (e.g., pre-pressurizing pneumaticbrakes), and/or pre-tensioning seat belt(s).

Specific Actions: braking, steering, engine braking or retarding,transmission gear shifts, adjusting throttle or torque requests, spoileradjustments, and/or differential steering.

Referring again to the table of FIG. 11, the checkmarks indicate whichcategory of preemptive action is available for each severity levelthreshold in accordance with this embodiment. Specifically:

Pre-warning or low security threat level: Warnings/Alerts and SafetyPreparations are available.

Moderate security level: Specific Actions.

High security: Safety Preparations and Specific Actions.

Emergency level: all three categories are available.

It should be understood that in any given circumstance, the threat leveldetermination module 904 may select any one or combination of preemptiveactions available in a given category once a threat severity level isdefined. Typically, all of the preemptive actions in a given categorywill not be selected. However, in certain circumstances, they all may beselected. It suffices to say that the module 904 has the ability to pickand chose the preemptive actions in a given category on a case-by-casebasis, depending on the totality of the circumstances represented by agiven threat.

Referring to FIG. 13, a flow chart 1300 illustrating operational stepsof a non-exclusive embodiment of the risk mitigation or avoidance system900/1000 is illustrated. With this particular embodiment, the preemptiveaction(s) taken by the following vehicle for each tier include:

-   -   (1) Pre-warning level: Warning and/or alert preemptive actions        are taken, but the platoon remains intact,    -   (2) Moderate level: The gap 808 is increased, but the platoon        remains intact;    -   (3) High security level: The platoon is dissolved; and    -   (4) Emergency level: Hard braking by following vehicle(s) 804        and the platoon is dissolved.

In the initial step 1302, the platoon controller 110/410 of two (ormore) vehicles coordinate to establish a platoon as described herein.

In step 1304, the one or more sensor(s) 902 on the lead vehicleinterrogate the space 810.

In step 1304, the environment in space 810, as perceived by processingthe data generated by the sensor(s) 902, is analyzed. As previouslydiscussed, the data can be processed by either the following vehicle804, the lead 802 vehicle or even possibly by a combination of both (ormore vehicles) in the platoon.

In decision 1308, a determination is made if there is a perceived hazardor not.

If not, then steps 1302 through 1306 are continually repeated so long asthe platoon is maintained.

On the other hand, if a threat is perceived, for example because athreatening object 806 is identified in the space 810, then the threatlevel determination module 904 (either in the lead or following vehicle)selects the appropriate tiered severity threat level commensurate withthe perceived threat. In this example, the severity levels include low(1310), moderate (1312), high (1314) and emergency (1316).

If the low security threat 1310 is selected, then module 904 defines theappropriate warnings and/or alerts in step 1318 and the actionimplementation module 906 implements those warnings and/or alerts instep 1320 in the lead vehicle 802 and/or the following vehicle 804.

If the moderate security level 1312 is selected, then the modules 904and 906 cooperate to control the velocity of the platooning vehicles(i.e., reduce the velocity of the following vehicle(s)) relative to thelead vehicle for the purpose of increasing the gap as provided in steps1322 and 1324 respectively.

If the high security threat 1314 is selected, then the modules 904 and906 cooperate to dissolve the platoon in a controlled manner as providedin step 1326. For example, the relative velocity of the followingvehicle is reduced, allowing the gap 808 to grow until the platoon isdissolved.

If the emergency security threat 1316 is selected, then the modules 904and 906 cooperate to first hard brake the following vehicle(s) in step1328 and then dissolve the platoon in step 1330. If multiple followingvehicles 804 are involved, it is preferred that the timing of the hardbraking occur in sequence, starting from the last vehicle to the leadvehicle.

Regardless of the tiered security level selected, control is returned todecision 1308. If the perceived hazard remains, then one of the securitylevels 1310-1316, and their subsequent actions, is performed until thethreat is no longer present and/or the platoon is dissolved. If thethreat is no longer present, then control is returned to step 1302, andnormal platooning proceeds. If the platoon was dissolved as a result ofa preemptive action, then the vehicles may decide to re-engage asdescribed above once the threat has passed.

EXAMPLES

To better explain the operation of the systems 900/1000 for mitigatingor avoiding risks encountered by platooning vehicles, several real worldexamples are provided and discussed below. In this example, thesensor(s) 902 on the lead vehicle are radar detectors capable ofdetecting or ascertaining the size and relative velocity of object(s)806 in space 810. Based on the size and relative velocity, the threatlevel determination module, optionally along with machine learningmodule 908, can identify object(s) 806 and the threat they mayrepresent. Again, the present invention is not limited to using radarsensors. As noted above, a number of different types of sensors can beused, either alone or in combination. For example, radar can be used incooperation with cameras. The radar can be used to identify the size andrelative velocity of object(s) 806 with respect to the lead vehicle,whereas images of the object(s) 806 can be used by learning module 908to precisely identify the objects.

Scenario One: In this example, a car enters onto a freeway via an onramp 50 meters ahead of a platoon of vehicles. Both the entering car andthe platoon are traveling at approximately the same highway speed. Since50 meters is generally considered a safe distance, and all involvedvehicles are traveling at approximately the same speed, any perceivedthreat will be low. As a result, simply warning and/or alerting theplatoon drivers and any other surrounding drivers, is an adequateresponse commensurate with the relatively low threat. As a result, thewarnings alerts, such flashing warning lights, vibrating the seats ofthe platooning drivers, setting off an audio warning, are typicallysufficient preemptive actions.

Scenario Two: In this scenario, the same car enters the freeway 50meters ahead of the platoon. However, rather than traveling at highwayspeed, the car is traveling only at 45 mph, or approximately 20 mphslower than the platoon. As a result, the severity level is moderate,meaning a collision is not imminent, but the lead vehicle of the platoonshould react (e.g., switch lanes and/or brake) action to avoid apossible collision. In this situation, the gap is increased withoutdissolving the platoon. For example, the gap can be increased from anormal operating condition of 12 meters to 24 meters by reducing thevelocity of the following vehicle(s). As the relative velocity of thefollowing vehicle is reduced and the gap grows, the lead vehicle canthen take precautionary action to avoid the car ahead. If braking isneeded, the likelihood of the following vehicle 804 colliding with thelead vehicle 802 is greatly diminished with a larger gap. When the carahead speeds up, and the perceived threat is diminished, then platooncontrollers 110/410 on the following vehicle can increase relative speedto reduce the gap to a normal operating distance (e.g., 12 meters).

Scenario Three: A car abruptly cuts off the platoon entering space 810immediately ahead of the lead vehicle. In this scenario, the platoon isnow dangerously tail-gating the car ahead, which represents a highsecurity threat if the car ahead suddenly brakes. In response, thesystem acts to dissolve the platoon, again by first braking or otherwisereducing the velocity of the following vehicle(s) versus the leadvehicle. Once the velocity of the following vehicle(s) is reduced, thenthe lead vehicle can brake or otherwise reduce its velocity. Since thefollowing vehicle started reducing its velocity sooner, it will slowdown quicker relative to the lead vehicle. As a result, the gap willwiden until the platoon is dissolved.

Scenario Four: A platoon crests a hill on a freeway and immediately seesstalled cars ahead and quick braking is required to avoid a collision.In this emergency scenario, the following vehicle immediately initiateshard braking (e.g., a Brake Now command), reducing its relative velocitywith respect to the lead vehicle and growing the gap and dissolving theplatoon. Once the following vehicle reduces its velocity, then the leadvehicle can brake and take other preemptive steps to reduce itsvelocity. Again, since following vehicle started slowing down first, thegap will increase as the two vehicles reduce their velocity.

In the various scenarios above, there are a number of situations wherethe following vehicle is required to reduce velocity prior to the leadvehicle doing the same. The Applicant has found that by initiatingreduced velocity of the following vehicle just a split second (e.g., ahalf second or less) ahead of the lead vehicle results in the size ofthe gap growing larger as both vehicles decelerate.

In various embodiments, the relative velocity between the two vehiclescan also be precisely controlled when either widening or dissolving thegap. For example, the rate of velocity reduction of the followingvehicle may range from (−0.1 to −2.0) meters per second relative to thelead vehicle. In situations where there are multiple following vehiclesin a platoon, the velocity reduction per vehicle can be successivelyincremented depending on vehicle position in the platoon. For instance,the velocity rate reduction for the second, third and fourth vehiclescan be incremented (−0.2, −0.4 and −0.6) meters per second respectively.By sequentially controlling the timing (i.e., initiating braking fromthe back to the front vehicle) and increasing the negative rate ofvelocity from the back vehicle to the forward vehicle, the gap betweeneach vehicle can be widened or dissolved in a controlled manner.

Alternative Embodiments

It should also be understood that the above embodiments of the riskmitigation and avoidance system 900/1000 are merely illustrative andshould by no means be construed as limiting.

For example, any number of severity threat levels or thresholds may beused and the number, type and/or specific preemptive actions percategory may widely vary. The above examples of four threat severitylevels, and the specific preemptive actions listed for each of the threecategories, should therefore not be construed as limiting in any manner.Any number of severity levels, categories and preemptive actions may beused.

In addition, it should be understood that while much of the discussionabove was provided in the context of a platoon including only twovehicles, again this should not be construed as a limitation of anykind. On the contrary, the gap control and risk mitigation or avoidance,as described herein, is applicable to platooning involving any number ofvehicles, regardless of vehicle type.

In yet other embodiments, the vehicles involved platooning and/or andrisk mitigation or avoidance can be autonomous, semi-autonomous, ordriven by a driver, or any combination thereof.

Pre-Cognitive Braking

Pre-cognitive braking is one particular pre-emptive action that can beused to mitigate or avoid risks due to hazards encountered by platooningvehicles. With pre-cognitive braking, when a lead vehicle 802 issues abrake command, the following vehicle(s) 804 is/are immediately informed,so that the following vehicle(s) 804 can take preemptive action,preferably before a change in speed of the front vehicle 802 occurs.

Referring to FIG. 14, a pair of vehicles 802, 804 operating in a platoonwith a gap 808 is illustrated. In this example, the lead vehicle 802initiates a braking command. In various embodiments, the braking actioncan be implemented or may result in a number of ways, such as but notlimited to, the driver braking (i.e., pushing the brake pedal), anactive cruise control system (ACC) initiating a braking action, or someother automated driving unit initiating the braking action. Regardlessof the origin, a braking notice 1402 of the braking command istransmitted by the lead vehicle 802 to the following vehicle 804. Withthe following vehicle 804 aware of the braking event, the braking actionof the two vehicles can be coordinated, avoiding or mitigating risks.

The notice information associated with the braking event 1402 sent fromthe lead vehicle 802 to the following vehicle 804 may widely vary. Indifferent embodiments, the relayed information may include a simplebrake command to more detailed information, such as brake applicationpressure, brake air supply reservoir pressure, engine torque, enginespeed or RPMs, compression (Jake) brake application, accelerator pedalposition, engine manifold air pressure (MAP), computed delivery torque,vehicle speed, system faults, battery voltage, radar or lidar data, orany combination thereof. Also, it should be understood that otherinformation besides braking commands may be sent between the vehicles802, 804. As a general rule, braking information is prioritized overtypes of non-critical information.

The information pertaining to the braking event 1402, as relayed via adata link established by the gateways 470 of the lead vehicle 802 andthe following vehicle 804. In various embodiments, the data link may beimplemented using WiFi, one or more designated radio channels, Zigbee orany industry or agreed upon standard radio. The above list is merelyexemplary. Any reliable, low latency data link may be used, having forinstance, a latency of 10 milliseconds or less.

Pre-cognitive braking involves, as referred to above, the coordinatedbraking action between the lead vehicle 802 and the following vehicle804. In some embodiments, the coordinated action involves initiating thebraking of the following vehicle 804 before the lead vehicle. In thisway, the gap between the two vehicles grows and the two (or morevehicles) may each brake in a controlled, safe manner.

Referring to FIG. 15, a diagram 1500 that plots the distance “D” of thegap 808 between the two vehicles over time while platooning isillustrated. Prior to a braking event by the lead vehicle 802,designated by 1502 in the plot, the gap distance D remains fairlyconstant, fluctuating only slightly as corrective action is taken by thevehicles to maintain the desired gap. When the braking action 1502occurs, the following vehicle 804 is immediately notified via the datalink. In this particular embodiment, the braking of the two vehicles iscoordinated such that the following vehicle 804 brakes (i.e., slowsdown) first before the lead vehicle 802. As a result, the gap grows asillustrated by the rise in the plot 808 after braking is initiated.

It should be understood that the aforementioned embodiment illustratedabove is merely illustrative and should be in no way construed aslimiting. In various alternative implementations, the braking behaviorof the two vehicles can be controlled in a variety of ways. Forinstance, the two vehicles can begin braking at substantially the sametime, but with the following vehicle braking harder than the leadvehicle. As a result, the rate at which the gap grows over time isincreased as the following vehicle reduces its speed at a quicker rate.This is just one possible alternative. Many other braking strategies, asdiscussed in more detail below, may be used.

Referring to FIG. 16, a flow chart 1600 illustrating the steps ofpre-cognitive braking are illustrated.

In the initial step 1602, events are monitored at the lead vehicle 802to determine if a braking event has occurred. Again, as discussed above,a braking event may be detected in a number of ways and is notnecessarily limited to the driver pushing the brake pedal. For instance,the braking event can be triggered by an active cruise control system(ACC) or some other automated driving unit initiating the brakingaction.

In step 1604, a notice of the detected braking event is communicated tothe following vehicle 804. The communication may take place over thecommunication link established between the gateways 407 of the twovehicles. In various embodiments, the communication includes a brakecommand along with possibly other information, such as brake applicationpressure, brake air supply reservoir pressure, engine torque, enginespeed or RPMs, compression (Jake) brake application, accelerator pedalposition, engine manifold air pressure (MAP), computed delivery torque,vehicle speed, system faults, battery voltage, radar or lidar data, orany combination thereof.

In optional step 1606, the following vehicle may implement a number ofbraking strategies. For instance, the braking at following vehicle maybe timed to occur a few moments before the braking action of the leadvehicle. Alternatively, or in addition, the following vehicle may becontrolled to reduce vehicle speed at a controlled rate that is moresignificant than the lead vehicle. As a result, the gap will widen asthe two vehicles reduce their speed.

Heavy vehicles, such as trucks or busses, typically rely on pneumatic orair brakes. These types of brakes use compressed air in a chamber,pressing on a piston, to apply pressure on to a brake pad that is usedto brake or stop the vehicle. When braking while driving, the drivertypically pushes the brake pedal, which forces air under pressure intothe chamber, causing the piston to apply pressure to the brake, slowingthe vehicle. With pneumatic brakes, the braking action may be delayeduntil there is adequate air pressure in the chamber.

In one non-exclusive braking strategy, the following vehicle 804 may inresponse to a received braking notice 1402 begin to immediatelypressurize its brake chamber(s) ahead of and/or more aggressively thanthe lead vehicle 802. As a resu the brakes may be applied by thefollowing vehicle 804 before the lead vehicle 802.

In yet other alternative embodiments, one or any combination of theabove-listed parameters may be used to formulate a braking strategy forthe following vehicle 804. With this information, the rate of braking ofthe following vehicle 804 can be calculated relative to the lead vehicle802. For example, the velocity reduction of the following vehicle 804may be controlled to be (−0.1 to −2.0) meters per second relative to thelead vehicle 802.

In step 1608, the braking, including the use of any particular brakingstrategy, occurs with the following vehicle.

In step 1610, the braking, including the use of any particular brakingstrategy, occurs with the lead vehicle after braking is initiated withthe following vehicle in the previous step.

Finally, the type of vehicles that may be used for platooning and/orrisk mitigation or avoidance may widely vary and are not limited toexclusively trucks. On the contrary, the present invention contemplatesthat any vehicle class or type may be used, regardless if powered by acombustion engine, electric motor, fuel cells, or any other possibleself-propulsion mechanism, including cars, trucks, buses, motorcycles,or any other self-propelled vehicle that is currently or may bedeveloped in the future.

Therefore, the present embodiments should be considered illustrative andnot restrictive and the invention is not to be limited to the detailsgiven herein, but may be modified within the scope and equivalents ofthe appended claims.

What is claimed is:
 1. A system arranged to operate on a followingvehicle in a platoon with a lead vehicle, the system configured to:receive a notice at the following vehicle from the lead vehicle of abraking event by the lead vehicle; in response to the notice,coordinating deceleration between the following vehicle and the leadvehicle such that: the following vehicle brakes before the lead vehicledecelerates; and the following vehicle reduces velocity more than thelead vehicle, wherein the combination of the braking of the followingvehicle before the lead vehicle and the following vehicle reducingvelocity more than the lead vehicle results in an increase of a gapbetween the lead vehicle and the following vehicle.
 2. The system ofclaim 1, further comprising, in response to the notice, coordinating thebraking between the lead vehicle and the following vehicle such that thefollowing vehicle reduces speed by (X) meters per second and the leadvehicle reduces speed by (Y) meters per second, where (X) is greaterthan (Y).
 3. The system of claim 1, further comprising, in response tothe notice, coordinating the braking between the lead vehicle and thefollowing vehicle by pressurizing pneumatic brakes on the followingvehicle and applying the brakes on the following vehicle before the leadvehicle.
 4. The system of claim 1, wherein the braking event by the leadvehicle is initiated by one of the following: (a) a driver of the leadvehicle; (b) an active cruise control system operating on the leadvehicle; (c) an automated driving unit operating on the lead vehicle. 5.The system of claim 1, wherein the lead vehicle and the followingvehicle are both tractor-trailer trucks.
 6. The system of claim 1,further comprising: a first communication gateway on the lead vehicle; asecond communication gateway on the following vehicle, wherein the firstand second communication gateways establish a data link between the leadand the following vehicles and the notice is communicated from the leadvehicle to the following vehicle over the data link.
 7. The system ofclaim 6, wherein the data link is wireless.
 8. The system of claim 6,wherein data link is implemented using one of the following: a DedicatedShort-Range Communications (DSRC) data link; a cellular data link; aWiFi data link.
 9. The system of claim 1, wherein the lead vehicle isfurther configured to communicate to the following vehicle, in additionto the notice, data indicative of one or more of the following: (a)brake application pressure; (b) brake air supply reservoir pressure; (c)engine torque; (d) engine speed; (e) engine Manifold Air Pressure (MAP);(f) speed of the lead vehicle; and/or (g) radar or lidar imagining. 10.The system of claim 9, wherein the following vehicle is further arrangedto use any of (a) through (g) to ascertain a rate of velocity reductionfor the following vehicle, relative to the lead vehicle, in response tothe notice.
 11. A system configured to operate on a following vehicle ina platoon behind a lead vehicle, the system configured to: receive datagenerated by one or more sensors arranged to interrogate a spaceradially extending from the lead vehicle as the lead vehicle travelsover a road surface; ascertain from the data a hazard caused by anobject in the space; and coordinating preemptive action, in response tothe ascertained hazard, between the lead vehicle and the followingvehicle while operating in the platoon, the coordinated preemptiveaction causing the following vehicle to take a first preemptive actionto avoid or mitigate a risk resulting from the hazard caused by theobject in the space, the first preemptive action taken by the followingvehicle coordinated to occur prior to the lead vehicle taking any secondaction to avoid or mitigate the risk resulting from the hazard caused bythe object in the space.
 12. The system of claim 11, wherein the firstpreemptive action comprises one or more of the following: (a) flashingor operating warning lights on the following vehicle; (b) operating ahorn on the following vehicle; (c) operating visual warnings on thefollowing vehicle; (d) operating haptic actuators on the followingvehicle; (e) manipulating a radio on the following vehicle; (f)preparations for braking; or (g) pre-tensioning seat belt(s).
 13. Thesystem of claim 11, wherein the first preemptive action comprises one ormore of the following: (a) braking; (b) steering; (c) engine retardbraking; (d) transmission gear shifts; (e) adjusting throttle or (f) atorque request; (g) spoiler adjustments; or (h) differential steering.14. The system of claim 11, wherein the one or more sensors on the leadvehicle comprise one or more of the following: (a) a radar detectionsystem; (b) a LIDAR or laser detection system; (c) a camera or imagingsystem; (d) a radio system; (e) an automated braking system; (f) anautomated collision avoidance system; (g) a GPS system; (h) cruisecontrol system; (i) passive sensors; and (j) active sensors.
 15. Thesystem of claim 11, further comprising a threat level detection elementarranged to interpret the data and to ascertain a hazard severity levelcaused by the object in the space.
 16. The system of claim 11, furthercomprising a machine learning element configured to ascertain a hazardseverity level caused by the object by using pattern recognition and alearning algorithm that aids in identifying the object and the severityof the threat caused by the object.
 17. The system of claim 11, whereinthe first preemptive action involves generating an actuator command foractuating an actuator on the following vehicle.
 18. The system of claim11, further comprising a first platoon controller for the lead vehicleand a second platoon controller for the following vehicle, the first andsecond platoon controllers communicating so that: (a) a desired gap ismaintained between the two vehicles during platooning; and (b) as aresult of the coordinated preemptive action, the platoon is dissolved.19. The system of claim 11, wherein the data is generated by the one ormore sensors on the lead vehicle, while the system on the followingvehicle is responsible for: (a) ascertaining the hazard caused by theobject; and (b) determining the first preemptive action to be taken bythe following vehicle.
 20. The system of claim 11, wherein the leadvehicle is configured to be driven by one of the following: (a) adriver; (b) an autonomous driving system; or (c) a combination of both(a) and (b).
 21. The system of claim 11, wherein the platoon can bedissolved by a decision on either the lead vehicle or the followingvehicle.
 22. The system of claim 11, wherein the lead vehicle and thefollowing vehicle are both tractor-trailer trucks.
 23. A The system ofclaim 11, wherein the first preemptive action taken by the followingvehicle causes the platoon to dissolve.
 24. A The system of claim 23,wherein the first preemptive action taken by the following vehicle tocause the platoon to dissolves involves initiating a reduction invelocity of the following vehicle with respect to the lead vehicle priorto the lead vehicle taking the second action to avoid or mitigate therisk resulting from the hazard caused by the object in the space. 25.The system of claim 24, wherein initiating the reduction in the velocityof the following vehicle is accomplished by one or more of thefollowing: (a) applying brakes on the following vehicle; (b) applying aretarder on the following vehicle; (c) adjusting the engine torque onthe following vehicle; (d) adjusting a tractive force; or (d) anycombination of (a) through (d).
 26. The system of claim 11, wherein thefirst preemptive action involves reducing the velocity of the followingvehicles relative to the lead vehicle, wherein the reduced velocityranges from (−0.1 to −2.0) meters per second relative to the leadvehicle.
 27. The system of claim 11, wherein a gap is maintained betweenthe lead vehicle and the following vehicle while operating in theplatoon and the first preemptive action taken by the following vehiclecauses an increase in the gap between the lead vehicle and the followingvehicle without dissolving the platoon.
 28. The system of claim 27,wherein the gap is increased between the lead vehicle and the followingvehicle by reducing the velocity of the following vehicle relative tothe lead vehicle.
 29. The system of claim 27, further configured to: (a)ascertain when the hazard caused by the object is no longer a threat;and (b) decrease the gap between the lead and following vehicles afterthe hazard caused by the object is no longer a threat.
 30. The system ofclaim 11, further configured to: define a plurality of tiered severitythreat levels, each of the plurality of tiered severity threat levelsdefining one or more preemptive action(s) respectively; selecting one ofthe plurality of tiered severity threat levels commensurate with theascertained hazard caused by the object in the space; and arranging forthe following vehicle to implement the first preemptive action, thefirst preemptive action commensurate with the selected tiered severitythreat level.
 31. The system of claim 30, wherein the plurality oftiered threat levels include: (a) a first warning threat level; (b) asecond gap increase level without dissolving the platoon; (c) a thirdplatoon dissolve level; and (d) a fourth platoon dissolve level withbraking by the following vehicle.
 32. A system operating on a leadvehicle in a platoon with a following vehicle, the system configured to:(a) ascertain a hazard caused by an object in a space adjacent the leadvehicle from data generated by one or more sensors on the lead vehicle;(b) determine a preemptive action for the following vehicle on the leadvehicle, the preemptive action for avoiding or mitigating a riskassociated with the hazard; and (c) relay one or more commands to thefollowing vehicle indicative of the determined preemptive action,wherein the following vehicle is arranged to implement the preemptiveaction in response to the relayed one or more commands.